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^Thcre  exists  a substantial  literature  on  productivity  aids.  Software  aids  have  been 
developed  in  areas  such  as  testing,  documentation,  programming,  design,  and  analysis. 
A survey  of  almost  five  hundred  organizations  was  performed  to  analyze  various 
aspects  of  software  maintenance,  A purpose  of  the  survey  was  to  analyze  the  use  of 
various  productivity  aids,  and  to  ascertain  relationships  between  their  use  and  main- 
tenance effort  and  characteristics.  Ihe  survey  indicates  that  no  productivity  aid  was 
widely  employed  in  system  development  and  that  many  productivity  aids  do  not 
address  perceived  problem  areas.  Areas  perceived  as  problems  include  user  involve- 
ment in  the  application,  handling  user  enhancements,  and  management  concerns  with 
resource  allocation.  Statistical  analysis  found  certain  tools  (HIPO,  automated  flow- 
charting, data  base  dictionaries,  and  test  data  generators)  (©c*  ^ o ^ 2-^ 
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•‘^morc  prevalent  among  organizations  with  larger  data  processing  budgets.  Use  of  HIPO 
(automated  flowcharts)  was  found  to  be  more  prevalent  among  younger  (older)  applica- 
tions. Data  base  dictionaries  and  test  data  generators  were  found  to  associate  with 
larger  systems.  Analysis  revealed  that  the  impact  of  the  use  of  tools  on  maintenance 
effort  is  dominated  by  characteristics  of  size,  number  of  reports,  system  development 
experience,  and  use  of  data  base  management  systems. 
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1 . INTRODUCTION 


The  use  of  productivity  aids  has  been  widely  advocated  as  a means  of  improving 
software  quality,  reducing  software  maintenance  effort,  and  in  some  cases,  reduc- 
ing development  costs  in  some  phases  of  design  and  implementation.  A variety  of 
tools  and  techniques  have  been  proposed  for  different  activities,  including  analysis 
(e.g.,  structured  analysis,  DBDA),  design  (e.g.,  structured  design,  ISDOS-PSL/PSA, 
top  down  design),  programming  (e.g.,  structured  programming),  documentation 
(e.g.,  HIPO,  automated  flowcharting),  management  and  review  (e.g.,  structured 
walkthrough,  chief  programmer  team),  and  testing  (e.g.,  test  data  generators). 

Less  consideration  has  been  given  to  impact  assessment  of  such  tooljs  and  tech- 
niques on  operational  systems.  Some  questions  that  arise  are: 


0 How  widely  are  such  tools  employed? 


Does  the  use  of  tools  reduce  maintenance  effort? 


Although  generalizations  must  be  made  with  caution  (due  to  organization  differ- 
ences, differences  in  systems,  etc.),  it  is  necessary  to  study  such  questions  to 
determine  where  improvements  are  needed  and  where  tools  may  be  helpful. 


The  preceding  discussion  of  tools  and  techniques  is  part  of  the  larger  problem  of 
understanding  development  and  maintenance.  Maintenance  here  is  defined  as  any 
work  on  a current,  operational  application  system.  Although  a great  deal  of 
effort  has  been  directed  at  development,  software  maintenance  has  received  less 
attention.  A review  of  the  literature  and  issues  in  software  maintenance  of  appli- 
cation systems  appears  in  Lientz  and  Swanson  (2).  Based  on  the  need  for 


I t 


3 


analyzing  maintenance,  a preliminary  summary  of  eighty-six  organizations  was 
undertaken.  The  survey  was  based  on  a questionnaire  in  managerial,  as  well  as 
technical,  aspects  of  maintenance.  The  results  of  the  survey  are  given  in  Lientz, 
Swanson,  and  Tompkins  (41  • ill  refer  to  this  study  later  as  the  initial  survey. 

Because  of  the  interest  generated  by  the  survey  and  because  of  the  need  for  a 
larger  sample  to  consider  specific  issues,  a larger  scale  survey  was  conducted. 
The  questionnaire  was  reviewed  and  revised.  It  was  divided  in  two  parts--Part  I 
dealing  with  the  organization  and  Part  11  dealing  with  a specific  application.  The 
Data  Processing  Management  Association  (DPMA)  agreed  to  support  the  survey  by 
providing  a randomly  generated  mailing  list  of  2000  data  processing  managers  and 
supervisors  as  well  as  an  enclosing  cover  letter  to  the  questionnaire.  Responses  to 
the  questionnaire  were  received  from  487  organizations.  This  response  rate 
(approximately  2^%)  is  considered  excellent  considering  the  length  and  corr:plexity 
of  the  questionnaire  and  the  factor  that  limited  resources  permitted  only  a post- 
card follow-up.  The  responses  were  edited,  keypunched,  and  verified.  Statistical 
analysis  was  performed  using  the  SPSS  Statistical  package.  Some  tabular  results 
of  questions  were  presented  at  the  Annual  DPMA  meeting  of  November,  197S  (see 
Lientz  and  Sw  anson  [3] ). 

In  this  paper  we  address  the  use  of  some  productivitiy  tools  and  techniques  in 
reference  to  maintenance.  U’e  consider  not  only  the  use  of  such  tools,  but  the 
environment  in  which  the  tools  are  employed.  The  environment  includes  organiza- 
tion size,  system  age,  system  size,  and  perceived  problem  areas  in  maintenance. 
A more  comprehensive  analysis  of  the  survey  is  currently  being  prepared  in  mono- 
graph form.  It  should  be  emphasized  that  no  judgement  is  being  applied  as  to 
whether  the  extent  of  maintenance  is  good  or  bad.  This  obviously  depends  on  the 
particular  setting  for  an  application. 
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2.  THE  MAINTENANCE  ENVIRONMENT 


Maintenance  and  operations  are  the  part  of  the  life  cycle  where  many  of  the  | 

benefits  of  productivity  tools  are  claimed  to  lie.  The  maintenance  environment 

includes  the  perceived  importance  of  specific  tools  and  techniques  as  well  as  their  j 

effectiveness.  Related  to  this  are  the  problem  areas  perceived  by  management,  | 

as  well  as  the  measurement  data  collected  during  maintenance.  More  technical 

parts  of  the  environment  include  the  sources  of  enhancement  and  maintenance 

requests,  the  size  and  growth  of  the  application  system,  and  the  age  of  the  I 

system.  | 

1 

i 

The  environment  can  affect  the  selection  and  use  of  specific  tools  and  techniques  I 

For  example,  if  data  is  not  collected  on  maintenance  effort,  it  may  be  difficult  to 
justify  productivity  aids  since  the  benefits  could  not  easily  be  quantified.  If 
design  problems  are  perceived  to  be  severe  or  documentation  is  faulty,  then  these 

I 

I 

areas  might  receive  more  attention  for  potential  improvement.  I 


o Organization  Environment 


I 

f 


1 

f 


\ 
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In  the  survey  we  asked  whether  application  programmers  and/or  systems 
analysts  doing  maintenance  were  organized  separately  from  those  doing 
system  development.  A separate  maintenance  organization  would  facilitate 
measurement  and  evaluation  of  tools.  The  response  of  the  sample  indicated 
that  only  16.2%  (79  out  of  >*17)  organized  maintenance  separately.  \^e  see 
from  this  that  the  measurement  problem  is  more  complex  in  the  vast 
majority  of  the  organizations,  because  of  a lack  of  separation. 
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If  productivity  tools  are  to  affect  maintenance^  then  we  need  to  know  how 

I . . 

much  of  the  total  systems  effort  is  involved  in  maintenance.  The  survey 
indicated  that  the  percentage  in  maintenance  has  remained  at  about  50%  (to 
be  precise,  *(S.5%)  over  the  most  recent  two-year  period.  We  also  asked  for 
the  percentage  of  application  programmers  and  systems  analysts  relative  to 
the  systems  organization.  The  average  was  approximately  t(0%.  Note  that 
one  could  then  estimate  average  estimated  improvement  of  a technique 
which  claimed  to  reduce  maintenance  by  X%.  Suppose  technique  Z claimed 
to  reduce  maintenance  by  20%.  The  net  savings  to  the  organization  would  be 
U%  (.2  X X .50)  of  the  total  systems  organization.  Of  course,  this  is 
fictitious  and  only  intended  to  show  how  the  impact  could  be  derived.  Each 
organization  would  have  to  be  addressed  separately  for  a specific  method. 
The  point  is  clear,  however.  The  impact  on  savings  is  limited  by  the  numbers 
of  programmers  and  systems  analysts  and  by  the  effort  in  maintenance. 

o Management  Controls  and  Measurement 

The  survey  asked  which  of  nine  management  controls  were  employed  in  miain- 
tenance.  The  results  appear  in  Figure  1.  Productivity  aids  are  sometimes 
claimed  to  reduce  the  number  and  extent  of  changes  to  the  system.  The 
figure  reveals  that,  for  many  organizations,  measurement  of  the  effective- 
ness of  tools  would  be  difficult  due  to  the  absence  of  accounting  controls. 
For  example,  some  methods  claim  to  reduce  testing  effort  by  insuring  system 
simplicity.  However,  more  than  U0%  of  the  organizations  do  not  have  a 
formal  re-test  procedure.  In  such  cases,  measurement  of  testing  effort 
would  be  difficult  and  would  rely  on  informal  testing.  This  is  particularly 
likely  to  be  the  case  in  smaller  organizations,  which  cannot  easily  absorb  the 
overhead  associated  uith  the  use  of  formal  controls. 
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Absolute 

Frequency 

(Percent) 

All  user  requests  for  changes  to  the  application 
system  must  be  logged  and  documented. 

(78.9) 

All  user  requests  for  changes  to  the  application 
system  must  be  cost  justified. 

160 

(32.9) 

All  troubles  encountered  in  the  operational  proces- 
sing of  the  application  system  programs  must  be 
logged  and  documented. 

250 

(51.3) 

All  changes  to  the  application  programs  must  be 

Jogi’ed  and  documented. 

375 

(77.0) 

All  changes  to  the  application  programs  must  undergo 
a formal  re-test  procedure. 

285 

(58.5) 

With  the  exception  of  emergency  fixes,  all  changes 
to  the  application  programs  are  batched  for  periodic 
implementation  according  to  a predetermined  schedule. 

137 

(28.1) 

A formal  audit  of  the  application  system  is  made 
periodically. 

158 

(32.4) 

Equipment  costs  associated  with  operating  and  main- 
taining the  application  system  are  charged  back 
(in  whole  or  in  part)  to  the  user. 

163 

(33.5) 

Personnel  costs  associated  with  operating  and  main- 
taining the  application  system  are  charged  back 
(in  whole  or  in  part)  to  the  user. 

150 

(30.8) 

r 


o Maintenance  and  Enhancement 

Since  specific  tools  address  individual  system  activities,  it  is  of  interest  to 
note  where  time  is  expended  in  maintenance  and  enhancement.  This  is  shown 
in  Figures  2 and  3,  respectively.  Allocation  categories  are  based  on  those 
developed  in  Swanson  [5j . Figure  2 reveals  that  about  <*096  of  the  effort  is 
expended  in  user  enhancements- -providing  new  features  or  capabilities.  Only 
12%  goes  to  fixing  programs  on  an  emergency  basis.  The  effort  to  improve 
documentation  and  improve  system  efficiency  together  consume  less  than 
10%  of  the  maintenance  resources.  Figure  3 provides  a breakdown  of  the 
<*0%  of  the  total  effort  in  maintenance  devoted  to  user  enhancemients. 
Almost  two-tliirds  of  the  enhancement  effort  is  seen  to  consist  of  giving  the 
user  "more."  The  rates  here  indicate  that  methods  addressing  reporting 
flexibility  uould  appear  to  be  of  substantial  benefit  in  maintenance.  We  will 
return  to  this  when  we  consider  problem  areas  perceived  by  management. 
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o Technical  Characteristics  of  Applications 


The  applications  studied  in  the  survey  were  those  which  involved  substantial 
maintenance  effort,  were  significant  to  the  organization,  and  which  had  been 
operational  for  at  least  one  year.  The  breakdown  of  applications  in  the 
survey  is  given  in  Lientz  and  Swanson  [3]  Of  interest  are  the  size  and  other 
characteristics  of  the  applications.  The  average  age  of  applications  was  four 
to  five  years.  The  average  number  of  programs  in  the  application  currently 
and  one  year  ago  was  respectively  126.5  and  115.6.  This  indicates  a growth 
of  about  10%  per  year.  The  average  number  of  source  language  statements 
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Figure  2:  Allocation  of  Effort  in  Maintenance 

Mean  Percent 

a.  Emergency  program  fixes  12.0  j 

b.  Routine  debugging  9.0 

c.  Accommodation  of  changes  to  data  inputs  and  16.8 

files  I 

d.  Accommodation  of  changes  to  hardware  and  6.0  j 

system  software  I 

I 

e.  Enhancements  for  users  40.3  | 

f.  Improvement  of  program  documentation  5.3  ! 

g.  Recoding  for  efficiency  in  computation  3.9 

Others  3.3 


i ■ 
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Figure  3:  Allocation  of  Effort  in  User  Enhancements 


Mean  Percent 


a.  Providing  new,  additional  reports 

b.  Adding  data  to  existing  reports 

c.  Reforrnating  existing  reports,  without 
changing  their  data  content 

d.  Condensation  of  data  in  existing  reports 

e.  Consolidation  of  existing  reports,  reducing 
tlx-  number  of  reports 


Others 
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increased  from  <t3.6K  to  48K--again  an  increase  of  about  10%.  The  size  of 
the  data  base  or  files  increased  by  5%  from  <»1.6  M bytes  to  t»3.8  M bytes. 

The  number  of  pre-defincd  user  reports  increased  from  an  average  of  U9.0  to 
53.8,  approximately  10%.  The  source  languages  used  were  dominated,  as 
expected,  by  COBOL  (51.6%).  RPG  was  second  at  22.U%,  followed  by 
Assembler  at  1 1.9%. 

The  composite  picture  here  is  that  the  dominant  language  remains  COBOL. 

Application  systems,  measured  in  a variety  of  ways,  are  growing  at  a rate  of 
about  10%  per  year.  Again,  we  must  caution  that  these  figures  are  based  on 
the  systems  selected  by  respondents.  In  terms  of  hardware,  the  10%  growth  j 

I 

rate  can  easily  be  accomimodated  by  increased  capacity  due  to  hardv.are  ! 

performance-price  ratio  improvements.  I 

i 

I 

o Perceived  Problem  Areas  ^ 

Respondents  v.ere  asked  to  indicate  the  severity  of  various  problems  on  a | 

scale  of  1 to  5,  interpreted  as  follows:  1 - no  problem  at  all;  2 - somewhat 

minor  problem;  3 - minor  problem;  U - somewhat  major  problem;  5 - major  ^ 

problem.  ; 

I 

I 

r 

The  rankings  based  on  medians  are  as  follows:  ^ 

! 
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Factors 


Minor  problem:  o user  demands  for  enhancements  and  extensions  to  the 
system* 

o competing  demands  for  maintenance  programming 
personnel  time** 

o inadequate  training  of  user  personnel* 
o turnover  in  u'er  organization* 
o meeting  schedule  commitments*  * 
o quality  of  application  system  documentation"*^ 

Somewhat  minor 

problem:  o motivation  of  maintenance  personnel 

o forecasting  of  maintenance  programming  requirements 
o maintenance  programming  personnel 
o unrealistic  user  expectations 
o adherence  to  programming  standards 
o adequacy  of  systems  design  specification 
o data  integrity  in  application  system 
0 processing  time  requirements 
o turnover  of  maintenance  personnel 
o changes  made  to  system  hardware  and  software 
o skills  of  maintenance  programming  personnel 
o quality  of  original  programming 
o number  of  maintenance  personnel  available 
o lack  of  user  understanding  of  application  systems 

No  problem:  o lack  of  user  interest 

o system  hardware  and  software  reliability 
o storage  requirements  of  application  system 
o budgetary  pressures 
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Reviewing  these  we  see  that  most  technical  issues  are  no  more  than  Some- 
what Minor.  In  the  Minor  Problem  category  we  have  labeled  issues  of  a user 
orientation  by  an  asterisk  (*),  a management  concern  by  a double  asterisk 
(••),  and  a technical  concern  by  a plus  (+).  Only  one  technical  issue 
appcars--quality  of  original  documentation.  Although  turnover  of 
maintenance  personnel  is  not  cited  among  the  top  problems,  eJscv.hcre  in  the 
survey  it  was  found  that  only  about  half  of  the  maintenance  personnel  were 
involved  in  the  development  of  the  system.  This  explains  in  part  the  need  for 
good  original  documentation  of  the  system. 


Of  tlic  six  Minor  Problem  concerns,  the  user  organization  is  involved  in  three. 
I'scr  demands  for  enhancements  has  already  been  mentioned.  Of  the  other 
two,  one  is  potentially  a management  issue--turnover  in  user  organizations, 
'iric  othcr--uscr  treining--could  be  addressed  by  applying  new  or  existing 
tecli-iiques. 

Trie  tv. o m.anagerr.ent  problems  perceived  as  Minor--competing  demands  on 
personnel  time  and  meeting  scheduled  commitments--reflect  a need  for 
riiciis'jrernent,  estirriation,  and  control.  Competing  demands  on  personnel 
lime  may  reflect  the  gap  between  limited  resources  and  user  r.cecs.  The 
problem  of  nieeting  scheduled  commitments  may,  in  pert,  be  due  to  a lack  of 
controls  and  data  from  which  to  estimate  effort. 

3.  USE  Of  TOOLS  AND  iiELATlON'SHlPS  ITH  OTHER  FACTORS 


'r 


0 I's^  of  Sclectrd  rrodurtivity  Aids 


In  th.c  iriitiiil  survey  the  sample  was  askvd  as  to  the  tools  cir.ploytd  in  tl.e 
ma.iitenance  of  the  system.  based  upon  these  findings,  a list  ol  tools 
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Figure  k:  Use  of  Design  and  Programming  Aids  In  Systems  Maintainance 


Tool 

Frequency  of 
Use  (Percent) 

a. 

Decision  tables 

k6.k 

b. 

Test  data  generator 

36.2 

c. 

Chief  programmer  team 

30.4 

d. 

» 

Online  programming 

30.4 

e. 

Database  dictionary 

26.1 

f. 

Structured  programming 

24.6 

g- 

Structured  alk-through 

17.4 

h. 

Automatic  flowciiarting 

10.1 

i. 

HI  PO 

7.2 

j- 

ISDOS  (Automated  design  aid) 

4.3 

t 

r 


i [ 

/ i . 


4 1 
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Figure  5:  Use  ol  Design  and  Programming  Aids  In  Systems  Development 


1 

a. 

Tool 

/ 

Absolute 

Frequency 

(Percent) 

Decision  tables 

161* 

(33.7) 

b. 

Data  base  dictionary 

73 

(15.0) 

c. 

Test  data  generators 

SO 

(16.4) 

d. 

Structured  programming 

145 

(29.8) 

e. 

Automated  flowcharting 

24 

(4.9) 

1. 

HlPO  (Hierarchy  plus  Input- Process-Output) 
Design  Aid  Technique 

34 

(7.0) 

g- 

Structured  walk-through 

82 

(16.8) 

h. 

Chief  programmer  team 

187 

(38.4) 

Others 

47 

(9.6) 

( 
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was  provided  in  the  expanded  survey.  Respondents  were  asked  to  indicate 
which  of  these  were  employed  in  the  development  of  the  system.  The  results, 
shown  in  Figure  4,  indicate  the  lack  of  tools  in  use.  However,  from  the 
previous  section  we  see  further  that  many  of  these  tools  do  not  address  the 
areas  of  concern  expressed.  Of  the  tools  in  Figure  5,  three  relate 
particularly  to  documentation  (HlPO,  decision  tables,  and  automated 
flowcharting).  However,  none  deal  with  the  user  and  management  problems 
cited. 

® of  Tools  and  Size  of  Data  Processing  Budget 


The  use  of  tools  was  analyzed  in  relation  to  the  size  of  the  data  processing 
installation  using  cross  tabulation  and  the  chi  square  test.  Larger 
organizations  tend  to  use  test  data  generators,  data  base  dictionary, 
autoinatic  flowcharting,  and  HlPO  (significance  levels--all  less  than  .0<*9o). 
Tfiis  is  to  be  expected  since  some  of  these  tools  require  a substantial 
hardware  envirotiment--more  likely  to  be  present  in  organizations  with  larger 
data  processing  budgets.  No  relationships  were  found  for  decision  tables, 
structured  programming,  or  structured  walk-throughs.  Use  of  a chief 
programmer  team  was  found  to  be  more  prevalent  for  organizations  with 
medium  range  data  processing  budgets  ($2>0,000  to  $200,000  per  year; 
significance  level--less  than  1%). 

o Use  of  Tools  and  System  Age  and  Siz.e 

Analysis  of  variance  was  employed  to  relate  systrrm  age  to  the  use  of  pro- 
du<  tivity  aids  in  development.  The  use  of  HlPO  was  significant!)  associated 
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with  younger  systems  at  the  5.5%  level.  The  use  of  automated  flowcharting, 
on  the  other  hand,  was  found  to  be  associated  with  older  systems  (at  the 
10.8%  level).  There  was  a limited  tendency  for  the  use  of  data  base  dic- 
tionaries, structured  programming,  and  structured  walk-through  with  younger 
systems,  but  this  was  not  of  notable  statistical  significance.  Decision  tables, 
test  data  generators,  and  chief  programmer  teams  did  not  associate  with  age. 


Similar  statistical  analysis  was  performed  for  the  number  of  programs  in  the 
system.  Significantly  associated  with  larger  number  of  programs  were  data 
base  dictionaries  (9.1%  level),  and  test  data  generators  (5.8%  level).  Analysis 
of  variance  for  the  rate  of  growth  in  the  number  of  programs  found  for 
increasing  growth  rates--data  base  dictionaries  (0.8%)  and  chief  programmer 
teams  (5.1%). 

o Use  of  Tools  and  Maintenance  Effort 


It  is  of  obvious  interest  to  determine  if  there  is  any  relation  between  the  use 
of  tools  and  the  amount  of  the  maintenance  effort.  A preliminary  effort 
suggested  variable  transformations  to  meet  normality  assumptions  in  the 
statistical  model.  Natural  logarithm  transforms  were  used  for  effort  and  size 
parameters.  Stepwise  linear  regression  was  performed  with  the  dependent 
variable- -the  natural  logarithm  of  maintenance  effort.  The  variables 
entered  in  order  were:  1 - natural  logarithm  of  the  number  of  programs  in 
the  system  currently,  2 - natural  logarithm  of  the  number  of  source  language 
statements,  3 - natural  logarithm  of  the  size  of  the  data  base,  <(- system 
development  experience,  5 - use  of  a data  base  management  system, 
6 - natural  logarithm  of  the  number  of  reports  generated  by  the  system 
currently. 
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The  seventh  variable  entered  is  the  first  evidence  of  a tooI--autornated  flow- 
charting. Overall  then,  the  analysis  indicates  that  the  tools  have  a limited 
relationship  with  maintenance  effort.  Using  a cut-off  level  of  F-1.0,  six  of 
the  eight  tools  eveotually  entered  the  regression  equation.  Even  though  the 
coefficients  of  the  tool  variables  are  very  low,  it  is  interesting  to  note  that 
some  may,  in  certain  cases,  appear  actually  to  contribute  to  increased  main- 
tenance effort.  The  variables  with  positive  relations  to  effort  are  automated 
flowcliarting,  data  base  dictionary,  structured  programming,  and  structured 
walk-through.  Tools  and  techniques  which  are  negatively  related  to  main- 
tenance effort  w ere  decision  tables  and  chief  programmer  teams. 

A similar  analysis  was  performed  with  the  dependent  variable  being  the 
number  of  persons  maintaining  the  system.  Here  the  only  tool  negatively 
related  to  the  number  of  people  in  maintenrince  of  the  particular  application 
was  the  chief  programmer  team.  Caution  in  interpreting  these  results  is 
needed  due  to  the  number  of  smaller  organizations  with  very  limited  main- 
tenance staffing. 

4.  CONCLUSIONS 

We  have  presented  some  of  the  results  of  a maintenance  study  from  the  per- 
spective of  the  use  of  software  productivity  aids.  The  findings  are  limited  by  the 
extent  of  the  survey.  It  should  be  emphasized  that  the  survey  was  limited  to 
standard  business  applications  rather  than  aerospace  or  engineering  applications. 
The  results  of  the  survey  are  that  many  productivity  aids  are  not  widely  used. 
Second,  the  areas  addressed  by  many  methods  niiss  areas  perceived  as  problems  by 
respondents.  Third,  there  arc  areas  that  deserve  more  attcntion--spccifically 
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techniques  that  enhance  the  users'  role,  and  methods  dealing  with  management 
concerns.  An  extension  of  the  findings  has  been  the  development  of  a long-range 
information  services  planning  methodology  which  has  the  control  of  maintenance 
and  enhancement  effort  as  one  of  its  goals  (See  Lientz  and  Chen  [l]). 
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There  exists  a substantial  literature  on  productivity  aids.  Software  aids  "aye 
been  developed  in  areas ’such  as  testing,  documentation,  ptogramming,  design,  and 
analysis.  A survey  of  almost  five  hundred  organizations  wps  performed  to  analyze 
various  aspects  of  software. maintenance.  A purpose  of  the  survey  was  to  analyze 
the  use  of  various  productivity  aids,  and  to  ascertain  relatfbnships  between  their 
use  and  maintenance  effort  and  characteristics.  The  survey  Indicates  that  no  pro- 
ductivity aid  was  widely’ em^oyed  in  system  development  and  that;^many  productivity 
aids  do  not  address  perceived  problem  areas.  Areas  perceived  .as  problems  include- 
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20.  (contd.) 
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user  Involvement  In  the  application,  handling  user  enhancements,  and  manag&ent 
concerns  with  resource  allocation.  Statistical  analysis  found  certain  tools  ' 

(HIPO,  automated  flowcharting,  data  base  dictionaries,  and  test  data  generators) 
more  prevalent  among  organizations  with  larger  data  processing  budgets.  Use  of 
HIPO  (automated  flowcharts)  was  found  to  be  more  prevalent  among  younger  (older)  . 
applications.  Data  base  dictionaries  and  test  data  generators  were  found  to 
associate  with  larger  systems.  Analysis  revealed  that  the  Impact  of  the  use  of 
tools  on  maintenance  effort  Is  dominated  by  characteristics  of  size,  number  of 
reports,  system  development  experience,  and  use  of  data  base  management  systems. 


I ■ 

I 

I 

I . 


'M, 


I 


